Date: Tue, 14 Jun 94 04:30:13 PDT 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V94 #194 

To: Ham-Digital 


Ham-Digital Digest Tue, 14 Jun 94 Volume 94 : Issue 194 


Today's Topics: 
An open note to Gary Coffman, KE4ZV (6 msgs) 
Need info on Ottawa PI Card 
Packet Ideas Sought... 
Thenet Eprom 1X for Thenet Node 
TM-733A and 9600 baud packet (3 msgs) 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Mon, 13 Jun 94 08:07:56 EDT 

From: world!mv!1mr!rapp@uunet.uu.net 
Subject: An open note to Gary Coffman, KE4ZV 
To: ham-digital@ucsd.edu 


Erich Franz Stocker <stocker@spsosun.gsfc.nasa.gov> writes: 


. stuff deleted 
( Using Packet nodes for Internet nodes doesn't hold much appeal for me 
either, although, there's nothing wrong with saving money!) 


While I can appreciate the BBS services of packet. I have to question 
this aS a main purpose in amateur radio. I'd like to see packet 

turn into a more real time "communications" avenue. Logging into a 
mail box isn't really radio. 


VVV NV 


I disagree, Erich. I think it's as much a part of radio as contesting, 
dxing, experimenting - all those different modes. Frankly, it seems to me 


that traffic handling and bbs's are the thing for which packet is most 
suited. Voice communications seem to me to be far more efficient for real 
time. This based on holding a ticket for 40 years now and getting into just 
about everything I could. :) 


73, 


Larry W1HIF 


L. M. Rappaport & Associates, Inc. rapp@lmr.mv.com voice +1 603 237 8400 
Colebrook, NH 03576-0158 CIS 72427 ,2567 fax +1 603 237 8430 


Date: 13 Jun 1994 12:58:32 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!gatech! concert! news- 
feed-1.peachnet.edu!news.duke.edu! godot.cc.duq.edu!codger! 
broderic@network.ucsd.edu 

Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


ae Mcmahon (packman@cix.compulink.co.uk) wrote: 

: > I'm aware that TCP/IP is already available. But this is a suite of 

: > programs which operate only through packet, if I'm not mistaken. > 

: Ideally,any program which can run through standard TCP/IP should be able 
: > to run through a packet-radio version of TCP/IP. As far as I know, 

: this > is not currently the case. 


: I've made the same comment to some of the TCP/IP fanatics in this area. 

: They seem to be happy with the various flavours of NOS/NET that exist. 

: I'd like to add some ‘features' to NOS, but I get put off by having to 

: try and figure out what the impact of my changes will be on the 350 (ish) 

: source code files that comprise JNOS (for example). What I'd ideally 

: like is a TCP/IP stack as a TSR that can have one or many hardware 

: drivers plugged into the bottom end and then present a standard API to 

: the programming world. Then standard telnet, etc could be used on top of 

: the TSR and I could write software using the API without having to worry 

: about messing up any of the underlying code. One possibility that could 
be used, although I've not explored it, is some of the Winsock software. 

: Unfortunately that means learning to write sensible Windows programs :-( 

: I'm talking 'IBM PC world' here, but the same could easily apply to other 

: environments. 

erties more deleted 

: Chris - G6FCI Packet : G6FCI @ GB7FCI.#16.GBR.EU 

: Internet : packman@cix.compulink.co.uk 


I was recently surprised to see references to ka9q code in a package 


of Ftp Software's PC/TCP for dos. This package comes with some 

winsock stuff (I think...), and although the source isn't available, one 
might coax an ax25 packet driver into working with it. I suspect that 
this is typical of many dos networking packages. 


As far as other computing environments, work done for Sunos, and recently 
Linux, points in this direction-- these provide kernel-layer interfaces 
to the ax.25 world. The chalenge now exists to write software to 

bridge between where packet users are today (mostly store/forward bbs 
style systems) to something a bit more transparent. 


Don Broderick N3GUZ 


Date: Mon, 13 Jun 1994 15:06:26 GMT 

From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory! 
rsiatl! ke4zv! gary@network.ucsd.edu 

Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


In article <X8XuNc7w165w@lmr.mv.com> rapp@lmr.mv.com (Larry Rappaport) writes: 
>Erich Franz Stocker <stocker@spsosun.gsfc.nasa.gov> writes: 

>> While I can appreciate the BBS services of packet. I have to question 

>> this aS a main purpose in amateur radio. I'd like to see packet 

>> turn into a more real time "communications" avenue. Logging into a 

>> mail box isn't really radio. 

> 

>I disagree, Erich. I think it's as much a part of radio as contesting, 
>dxing, experimenting - all those different modes. Frankly, it seems to me 
>that traffic handling and bbs's are the thing for which packet is most 
>suited. Voice communications seem to me to be far more efficient for real 
>time. This based on holding a ticket for 40 years now and getting into just 
>about everything I could. :) 


I agree with Larry, realtime "chat" mode is about the worst use for 
packet. We have other modes that are much better suited to this type 
of use. Packet is useful for the things it can do better than other 
modes, and store and forward is a primary example of where packet 

is superior to other modes. Packet does that well, but it isn'ta 
substitute for a microphone when the need is for realtime person to 
person communications. Hopefully, as the network speed increases, 
realtime machine to machine communications will become an important 
application facilitator, but right now non-realtime store and forward 
is the niche best served by packet. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


| gatech!wa4mei! ke4zv! gary 
| uunet!rsiatl!ke4zv! gary 
| emory!kd4nc!ke4zv! gary 

| 


Date: 13 Jun 1994 12:31:10 -0700 

From: mdisea!not-for-mail@uunet.uu.net 
Subject: An open note to Gary Coffman, KE4ZV 
To: ham-digital@ucsd.edu 


In article <X8XuNc7wl65w@lmr.mv.com>, Larry Rappaport <rapp@lmr.mv.com> wrote: 


>suited. Voice communications seem to me to be far more efficient for real 
>time. 


Maybe from the standpoint of the user but not from the standpoint of channel 
usage. There's a reason the phone companies have gone digital /:) What we 
ought to have is packet voice! 


Hugh Shane | 206 487 5909 (PST) 
Motorola Wireless Data | N7UAX 
shane@mdd.comm.mot.com | #include <std_disclaimer.h> 


Date: 13 Jun 1994 21:13:03 GMT 

From: ihnp4.ucsd.edu!swrinde! gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu! 
yeshua.marcam.com!news.kei.com!ssd.intel.com!chnews! cmoore@network.ucsd.edu 
Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


Hugh Shane (shane@mdd.comm.mot.com) wrote: 


: There's a reason the phone companies have gone digital 
: Hugh Shane | 206 487 5909 (PST) 


Hi Hugh, last time I checked, the initial deployment of IS-54 (digital) 
was no more bandwidth efficient than NAMPS (analog). And GSM (digital) 
is worse than NAMPS. 


73, KG7BK, OOTC, CecilMoore@delphi.com 


Date: 14 Jun 1994 00:36:33 GMT 

From: koriel!newsworthy.West.Sun.COM!abyss.West.Sun.COM!spot!myers@ames.arpa 
Subject: An open note to Gary Coffman, KE4ZV 

To: ham-digital@ucsd.edu 


In article 685@microsoft.com, davidar@microsoft.com (David Arnold) writes: 


>However, there are going to be some who will not want to dedicate a PC 

>to the problem. The problem can be solved in software, but the software 
>solution would only solve a particular platform configuration. 

>For example, if someone were to write a AX.25 NDIS driver, that would 

>solve the problem for a MS-DOS TCP/IP stack which support NDIS at the bottom, 
>which, BTW, is probably very common. 


Not a bad idea. In the System V world, an AX.25 Streams module would be 
cool, though a really good one would allow both AX.25 sessions and 

other networking sessions, and would be a multiplexor module, not as 

easy as a straight AX.25/IP module. NDIS should be pretty straightforward, 
though I have to write an NDIS driver. 


>Can you imagine running PC Mosiac for an Amateur Radio WWW? 


No. Well, on second thought, I can. It would suck. Here's a :-) for those 
who need it. 


* Dana H. Myers KK6JQ, DoDé#: j | Views expressed here are 
* 

* (310) 348-6043 | mine and do not necessarily * 

*x Dana.Myers@West.Sun.Com | reflect those of my employer 
* 


x This Extra supports the abolition of the 13 and 20 WPM tests x 


Date: Mon, 13 Jun 1994 21:39:35 GMT 

From: microsoft!wingnut!davidar@uunet.uu.net 
Subject: Need info on Ottawa PI Card 

To: ham-digital@ucsd.edu 


Where can I get one, company contact names, etc. 
Thanks. 


davidar@microsoft.com 
KD6IFY 


Date: 14 Jun 1994 02:15:46 GMT 

From: ihnp4.ucsd.edu!dog.ee.1lbl.gov!agate!darkstar.UCSC.EDU!news.hal.COM!olivea! 
news. bu.edu!dartvax.dartmouth. edu! usenet@network.ucsd.edu 

Subject: Packet Ideas Sought... 

To: ham-digital@ucsd.edu 


I'm thinking this summer about what I might want to do for a 
senior thesis in computer science next year, and I've decided that if 
it is possible, I would like to do something involving packet radio. 

Im still trying to think of something to do, however. I have a few 
thoughts: 

The focus of whatever I do is probably going to revolve around the 
nature of the amateur network as a fairly slow one (1200-9600 baud with 
rare exception.) It is also currently almost entirely accessed through 
text based terminal programs. There are a few specialty products on 
the market, but these are all most entirely specialty terminal 
programs. So, I could possibly explore something about the nature of 
the interface used to access the services in the network. I could 
possibly explore the use of something like an X Window system or 
similar open protocol for graphically-oriented distributed, 
client-server programs. 

Or I could possibly explore the netwrk for another angle, and ask 
the question "what services should be provided and how can they be best 
provided?" "What sort of changes/enhancements in the network will be 
the most beneficial to the user community?" Is there something like 
hypertext that will greatly improve the nature of the network? 

If you have any thoughts on this, I would appreciate it if you 
would drop me a line, or start up a general discussion of it here. I'm 
just sort of collecting thoughts at this stage, so anything might help. 

Also, if anyone knows of a good source for technical documentation 
on AX.25 or TCP/IP or the packet network in general, I would appreciate 
the pointers. 

Thanks and 73's... 


Kenneth E. Harker N1PVB Dartmouth College Amateur Packet Radio 
kenneth.e.harker@dartmouth.edu Hinman Box 1262 nipvb@wiet.nh.usa.na 
(603) 643-5716 Hanover, NH 03755 or nipvb-5 on 144.99 


Date: 14 Jun 1994 08:55:09 GMT 
From: ihnp4.ucsd.edu!swrinde!howland.reston.ans.net!xlink.net!scsing.switch.ch! 
swidir.switch.ch!univ-lyon1.fr!lanpc1.univ-lyon1.fr!cerdini@network.ucsd.edu 


Subject: Thenet Eprom 1X for Thenet Node 
To: ham-digital@ucsd.edu 


I'm looking for contents of Thenet Eprom 1X for Thenet Node (data which are 


loaded in TNC eprom)... Someone know where I can found that ? 

Michel CERDINI - Universite Lyon 1 | E-Mail cerdini@lan1.univ-lyon1.fr 
Laboratoire d'Analyse Numerique URA 740 | Tel Pro 72 43 10 93 - aka Djoe 
43, boul. du 11 novembre 1918 | Minitel 78 36 19 96 (24h/24) Vv 
69622 Villeurbanne Cedex, France. | Modem 78 36 10 01 (V-Fast) _/ 


Date: 13 Jun 1994 15:29:04 GMT 

From: ihnp4.ucsd.edu!usc!nic-nac.CSU.net!charnel.ecst.csuchico.edu!olivea!ncd.com! 
newshost.ncd.com!hansen.ncd.com! phil@network.ucsd.edu 

Subject: TM-733A and 9600 baud packet 

To: ham-digital@ucsd.edu 


I have a TM-733A and I would like to talk with others who are currently using 
it for 9600 baud packet... 


I would like to know what TXdelay you are running. I seem to have to keep 
TXDelay at 18... Which seems long. Other than that... It seems to work 
perfectly! 


Phil 
de kj6nn 


Date: 13 Jun 1994 16:08:50 GMT 

From: news.larc.nasa.gov!arbd0.larc.nasa. gov! zawodny@ames.arpa 
Subject: TM-733A and 9600 baud packet 

To: ham-digital@ucsd.edu 


In article <2thu00$18f$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) 
writes: 

>I have a TM-733A and I would like to talk with others who are currently using 
>it for 9600 baud packet... 

> 

>I would like to know what TXdelay you are running. I seem to have to keep 
>TXDelay at 18... Which seems long. Other than that... It seems to work 
>perfectly! 

> 


Wow! I'd love to be able to set my TXDelay at 18 (180ms). I currently have to 


set it to 40 with my GE Custom MVP. Anyone got any ideas how I can speed my 
MVP up? How about mods for 9600 buad? 


Joseph M. Zawodny (KO4LW) NASA Langley Research Center 
Internet: zawodny@arbd0.larc.nasa. gov MS-475, Hampton VA, 23681-0001 
Packet: ko41w@n4hog.va.usa 


Date: 13 Jun 1994 20:59:15 GMT 

From: usc!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu! 
yeshua.marcam.com!charnel.ecst.csuchico.edu!olivea!ncd.com!newshost.ncd.com! 
hansen.ncd.com! phil@ihnp4.ucsd.edu 

Subject: TM-733A and 9600 baud packet 

To: ham-digital@ucsd.edu 


I thought that most 9600 baud folks were trying to run with a TX delay of 7 to 
9 (aka 70 to 80 ms)... 


How about it... What is common for 9600 baud? 


phil 
de kj6nn 


In article <2tiOai$f9p@reznor.larc.nasa.gov>, zawodny@arbd0.larc.nasa.gov (Joseph 
M Zawodny) writes: 

|> In article <2thu00$18£$1@rosebud.ncd.com> phil@hansen.ncd.com (Phil Graham) 
writes: 

|> >I have a TM-733A and I would like to talk with others who are currently using 
|> >it for 9600 baud packet... 

|> > 

|> >I would like to know what TXdelay you are running. I seem to have to keep 

|> >TXDelay at 18... Which seems long. Other than that... It seems to work 

|> >perfectly! 

|> > 


|> Wow! I'd love to be able to set my TXDelay at 18 (180ms). I currently have to 
|> set it to 40 with my GE Custom MVP. Anyone got any ideas how I can speed my 
|> MVP up? How about mods for 9600 buad? 


Date: Mon, 13 Jun 1994 15:09:52 GMT 
From: world! dts@uunet.uu.net 
To: ham-digital@ucsd.edu 


References <2tfOkb$rql@eldborg.rhi.hi.is>, 
<1994Jun12.140915 .1245@ke4zv.atl.ga.us>, <wb6wCrB332.H30@netcom.com>dts 
Subject : Re: info wanted: new Kantronics 9k6 modem 


In article <wb6wCrB332.H30@netcom.com> wb6w@netcom.com (Glenn Thomas) writes: 
>Gary Coffman (gary@ke4zv.atl.ga.us) wrote: 

>: In article <2tf£O0kb$rql@eldborg.rhi.hi.is> bnt@rhi.hi.is (Benedikt Sveinsson) 
writes: 

: >Hello. 

>I was just hearing about the new Kantronics 9k6 packet 

>modem. I saw the advertisment in QST, but no price or 

>free the MFJ from the packet only operation on my BBS. 


: The Kantronics 9600 baud modem is a G3RUH copy, like the MFJ 

and the PacComm. The only difference is in form factor of the 
card to fit the different TNCs. Street price is in the range 

of $87-$109 at most shows. Aside from kludging the packaging, 
your MFJ 9600 baud modem will work in the KAM. 


: Gary 


VV VV NV VV VV VV VV 


>Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep 
>about the KAM and 9600 and was told that the KAM does its HDLC processing in 
>software rather than the hardware implementation that the TAPR II and clones 
>use. The software is fine for 1200 baud and slower, but just can't handle 
>9600. The Kantronics data engine does work very well at 9600 and a G3RUH 
>clone ought to work well in an TNC II clone. 

> 

>Oh...I understand that the KPC-3 also does HDLC in software, so it will never 
>do 9600 either. 


Kantronics has just announced a new box that handles one port for 9600 packet 
and another for 1200 packet. The HDLC framing is in software. Keep in mind that 
there is absolutely nothing wrong with using a software solution. It allows 

a MUCH simpler method for providing fixes should a problem be found. Suppose 
you find a bug in an HDLC-capable SCC chip? The usual answer to that is to 

live with it... 


I'm looking forward to trying one of the new Kantronics 9600 boxes... 


Dan N1JEB 
Daniel Senie Internet: dts@world.std.com 
Daniel Senie Consulting nijeb@world.std.com 


508-779-0439 Compuserve: 74176 ,1347 


Date: Mon, 13 Jun 1994 12:43:59 GMT 
From: ihnp4.ucsd.edu!swrinde! emory!rsiatl!ke4zv!gary@network.ucsd.edu 
To: ham-digital@ucsd.edu 


References <2tf£Okb$rql@eldborg.rhi.hi.is>, 

<1994Jun12.140915 .1245@ke4zv.atl.ga.us>, <wb6wCrB332.H30@netcom. com> 
Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman) 

Subject : Re: info wanted: new Kantronics 9k6 modem 


In article <wb6wCrB332.H30@netcom.com> wb6w@netcom.com (Glenn Thomas) writes: 
> 

>Actually, I don't think the KAM can do 9600 at all. I asked the Kantronics rep 
>about the KAM and 9600 and was told that the KAM does its HDLC processing in 
>software rather than the hardware implementation that the TAPR II and clones 
>use. The software is fine for 1200 baud and slower, but just can't handle 
>9600. The Kantronics data engine does work very well at 9600 and a G3RUH 
>clone ought to work well in an TNC II clone. 

> 

>Oh...I understand that the KPC-3 also does HDLC in software, so it will never 
>do 9600 either. 


Hmm. Good point Glenn. I used real TNC2 type TNCs when I was using 
TNCs. I had forgotten that the Kantronics boxes are gutless wonders. 
Still, I do know that the Kantronics 9600 baud modem that fits the 
Data Engine (and the Gracillis PacketTwin) is a G3RUH clone, and will 
work with MFJ and PacComm TNCs, though it's physically the wrong shape 
to fit in the cases. 


Gary 

Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


gatech!wa4mei! ke4zv! gary 
uunet!rsiatl!ke4zv! gary 
emory!kd4nc!ke4zv! gary 


You make it, 
we break it. 
Guaranteed! 


End of Ham-Digital Digest V94 #194 
KKKKKKKKKKKKK KKK KKKKKEKKEKRKE KAKI 


